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ABSIBiCT ^ 

The planning forr design^ and implementation of 
information management systems in colleges and universities is 
approaching a state of adolescence as a science. Eecause rules 
be devised with sufficient scope and dfipth to^^cover all institu 
and systems contingenciesr. the necessary activities remain some 
between magpie and art. At least 10 different efforts should be 
in the early stages of systems planning which relate to f acilit 
managementr a systems committee^ the user liaison functionsr 
seminars^ data base management ^ advisory committees^ implementa 
task groups, a procedures committeer user training, and evaluat 
Attachments include a systems seminar model for increased parti 
consciousness in a planned organizational change, a systems sem 
end-of -meeting evaluation instrument, a responsibility statemen 
data base^administratcrs,- u^er module checklist tables, and a 
tndversity procedures committee responsibility matrix. 
(Author/CHV) - ^ 4 * v . 
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The planning for, design and implementation of information 

management systems in colleges and universities is approaching 

a state of adolescence as a science. Because we cannot devise 

If 

"rules" with sufficient scope and depth to cover all insti- 
tutional and systems contingencies, the necessary activities 
remain somewhere between magic and jart. A€ least ten "things" 
can and should be done in the early stages of systems planning. 

These relate to facilities management, a systems committee, 

ft*- 

the user liaison funct^'ons,/ seminars, data base management, 
advisory committees, implementation task group^, a procedures 
ccmmittee, user trainirvg, and evaluatioris. 
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PART I 

PERSPECTIVE: FOCUSING ON THE TARGEl 



\PEPPERDINE UNIVERSITY ^ . 

\ — ~ . 

— P6pperdinfi-Untversity-was-estabTished-in~1937--t 



of Gfeorge Pepperdine' (1886-196^) , founder and developer of the Western Auto 
Supply Company.- The school was primarily an undergraduate college, af- 
filiated v/ith the Churches of Christ and. dedicated to promoting liberal 
arts education* with a Christian atmosphere. ^ , 

The school opened as Pepperdine College on the 35^acre original site 
'in south-central Los -Angeles, ^ with 137 students. A grant by the founder 
provided for "^he campus,, buildings, and an endov/ment of approximately two 
.million dollars; , . 

An enormous growth period ensued in the late 1960's and early 1970's 
(see^ Figures 1 and 2) as Pepperdine rapidly expanded from a single under- 

gradu;ste institution to a multi-ckmpused operation of five schools and many 

'V ' ^ ■ ■ 

off-campus locations. 

In 1972, the 650-acre Kalibu Campus, site of Frank R. Seaver College, 
opened with 872 students. As of the current school year, 1977-78, Pepperdine 
Schools of Professional Studies, Business and Management, and Education are 
administered from the LoS Angeles .Campus. Pepperdine' School of Law, pres-- 
-ently located. in Anaheim, will be joining Frank R. Seaver College, the 

traditional 4-year uhdergradu^ite college at the Malibu Cafnpus, in September, 

:. , . " • ■ - . L 

1978. \ / ' \ • 

'Adcling \:bniplexity to this phenomena = growth aref off -campus teaching 

locations, weekend mode courses, multi-disciplinary courses, a one-year. 

■ ■ ■ f . . ' * 
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European' program and extensive military programs on a world-wide basis, 

- The challenges' which raust be met ^ue to this rat^ of change are 
most evident in the areas of Student and Financial Records, As the 
technical needs of the systems change, so is it necessary to restructure 
and redefine the procedures and functions that the staff have been v/orking. 



wit^ in the past, a task at least as important as the technical modifi- 
cations, /T \ 
- UNIVERSITY INFORMATION SERVICES V* * " ^ 

The coordination of such extensive adminisitrat:ive changes involving 
computer systems became the .responsibility of University .Information 
•Services (UIS). UIS was originated for the purlofee of developing a Man- 
agament Information 'System rather than a dita processing operation in ♦ ^ 
order th^t overall administrative/academic needs could be met in a unified 
way,' and future planning and information reporting could be correlated with 
the current .data processing done in support of t^e administrative systems. 
In effect, UIS has become a change ageni^^for the University in .the sophis- 
ticatior^. and refining of Pepperdine's systems requirements, 

UIS has two primary objectives: (T) to provide management infor- 
mation to all divisions and administrative levels of the University, 
InpJ^iding information pertaining to decision-making needs and information 
related to. ope rati on of administrative systems; and (2) to provide tech- 
nical expertise for the design, implementation, operation, and ongoing 
maintenance of systems softv/are and hardware, both aiihinistrative and . 
academic. - 

. Organizationallyj; UIS reports directly to the Executive Vice President, 
the chief operations officer for Peoperdine University (see' Attachment A). 



The organization itself is headed byVh^xecutive Director who has direct 
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oversight of the Adinim* strati ve Staff, Institutional Research, and Computer 

Services units (see Attachment B, page !)• 

• ■ ' • * ' ^ •• •• . •. • - " • . 

Several dramati cooccurrences within a relatively s^ort time frame have 

. had a large impact on the University. These includedi: purchase and • 

< installation of a major computing device (a Un.ivac 90/60 computer); design 

J _■ • _» _. ^ 

and construction of a facility to house the ComputerLand staff (a two- 

&t6ry, 7,000 square foot buildingh conversion of some programs and all 

data from the external Service Bureaus v/hich had been prsed for Administrative 

* 1 ' ' ' • • * 

Services prior to the Univac 90/60; performance of ongoing routine reporting 

• futictions; and hiring, integrating, and training personnel to support an 
internal computing facili.tv. 

Total redesign and new programming effort for all administrative sbft- 
. ware has /been started, Thd 'Integrated Student Information System (ISIS) 
has been completed. Other primary administrative software such as the 
Integrated Business Information System (IBIS) are in the initi.al design 

• 'Stage'. Building a research data base for trend "analysis from past and cur- 
<rent information is- also in !progres§. 

The change process is dramatically affected by the organizational 
management style. In fact, the change strategy may be dictated by it. 
The, approach tb^management in UIS is derived from ^revisionist theory 
' social systems model: specl^fically, UIS's Executive Director's modified 
version of the Getzels-Guba "Nomothethi'c-Idiographic" model, ^ o 
^ This model stresses: (1) the group as the basic organizational unit; 
(2) a well-defined formal structure supplemented by informal communication 
channelsr (3) authority derived from knowledge, skill and achievement 
whenever possible; (4) control and feedback, closely related to group pro- 



cesses"; (5)." decision-making conducted at the most appropriate level; 
(6) goal -setting with as much group participation as possible; (7) 
communication vertically and hprizontally occurring without .fi 1 taring; . 

(8) ' motivation directly related to the individual's, role definition;' 

(9) a project approach to problem-solving; and (10) an atmosphere re- 
— captive J:o-4TVternaI--chaage — : — — 



The strategy being implemented ty UIS is a ndrmativen^^educative 

■ ' * 2 

model very similar to. -^he^problem-splving construct described by Novotney 

^with the. introduction *of a semi-pennanent Outsi^Je/inside change agent. 

r ' . ' . . PART 2 . 

FACILITY MANAGEMENT;- ■ .INTEGRATION WITH EXISTING ORGANIZATIONS 



■ r ^ - 

S^ST^MS & COMPUTER TECHNOLOGY CORPORATION . 



Thd outside change a^ent is Sy5tems.& Computer Technology Corporation 

(SCT)/a facilities management/educational software firm with extensive 

L/ - - . ( ■ , 

= — ^Xperjience spanning ten years in more than one hundred colleges and 

• universities. • 

JsGT has a five-year contract jwith Pepperdine to provide management 
and technical expertise- in the Computer Services areas of Computer Operations, 
Adminiistrative Systems and Academic. Computing. Manage rs-e*^hese areas . 
reporii directly to the Director of Computer Services., The Assistant Director 

- immediately superv/ses Administrative System's which is comprised of Student ' 

Records, Financial Records^ and User Liaison. All managers of these_units 

' ■ . ■ ^ ■ 

. are 'SOT employees. Successive positions are held by both Pepperdine and 
SOT personnel (see Attachment B, pages 2-4). 

SOT personnel work to identify -University ne'eds, to provide certain 



technical skills to the Urfiversity, tb train University staff, to^proy^ide 
.support for training, to arrange access, to other training resources, to 
'coordinate administration ^nd training as pa'rt of the system^s problem- 
solving procedures^ to act as a solution giver, to act as a process 

helper, and to act as a catalyst. The roles vary depending upon direction 

^ :_3 , „ _ „_„ , _ : 

from the University. . ^ 

All SCT activities are under the^irect supervision of the- UIS Execu- 
tive Director who coordinates their eTforts v/ith University personnel to 
produce concise problem statements, to analyze problems, to form objectives 
to solve problems, to condjict an inventory- of the necessary resources 'to 
solve identified problems/, to develop plans which will allow objectives to 
be reached, to help in the evaluation process^ during implementation and in» 
the determination of how well objectives v/ere met, ahd to bring about any 
•a-lterations (dictated by the evaluative: feedback.^ . 
INTEGRATION OF^ SCT. INTO UIS , ; / 
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Thexfunctions of the inside agent(s) . (the UIS Executive Director and 
/ ■ ■ . • 

his . staff) are critical in seeing that changes brought about by the "outside" 

'impetus beco(ne a stable part of the ongoing operation and that they have a 
broad tfase|of acceptance. Thus, the first task v/as to integrate SCT manage- 
ment and new Pepperdin^ employees into the UIS organization. Several actions' 
wer6 specified to take p,lace in this endeavor: . (1) the UIS Executive 
.Director interviewed and approved alVSCT managers prior to their assi gn- 
ment to Pepperdine, (2) Each Pepperdine employee transferred to UIS was 
• given an individual and -a group orientation to the goals and expectations 
of UIS, (3) The SCT managers conducted individual and group orientations 
with the- unit they supervised. (4) Detailed job descriptions and specific . 

■ ■ '. - . --5- ■ ■ ■ / ■ 
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Individual assignments were distributed and discussed with all new em- 
ployees and with UIS employees who reported to SCT mana^ement.^ (5) An 
all -day complete staff UIS orientation session was conducted. (5) A 
weekly meeting in which all .UIS managers report plans and project progress 
' to the Executive Diirectbr was established. (7) An ombudsperson position 

— r«porJ:i ng--to_tha--Execu.t.lve --Direct or- was^e 

orientation manual describing UIS goals, policy and procedures, organiza- 
tional structure, the SCT role, and the UlS/Uni versity rellati.onship^vas 

prepared and distributed to each UlS^employee. (9) Meetings were scheduled 

■* ' ■ 

and conducted with deans and representatives from. each sch'ool in the 

University to define and discuss the new UIS role and the SCT involvement 

in it. (10) Similar meetings wer^ hQld with all administrative^ units. 

(11) Several conrnit tees (which v/i 11 be discussed jn detail later) were 

appointed in an attempt to ensure university -wide input. and to facilitate 

information dissemination. (-12) The policy of weekly meetings to discuss 

sche^dules, problems or modifications with major ''^s terns . users was continued. 

Finally, (13) a monthlyyneeting where the 'Director of Computer Services 

presents a formal progress report to the Systems Committee (the policy- 

^ ■ ■ ✓ ' -I 

making body for UIS) v;as established. . / 

/ PART 3 

. A SYSTEI^ COf^-lITTEE: COMPOSITIOrt AND CHARGE 

Ensuring that UIS meets the objectives for which. the department was 

created, the President of * the University has established the Pepperdine ' 

University Systems Committee with the fol"! owing, make-up and charger 

The 'Pepperdine University Systems Committee is com-, 
pose'd of the Executive Vice President, who serves as 
. Chairperson, the Senior Vice President, the ^Vi(^e ^ 
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President of Academic Affairs, the Vice President 
. .of Administrative Affairs^ the Vice President of 
Financial Affairs, the Vice President of University 
Affairs, the Vice President/^ind Dean of the School 
'Of Business and Management, the Associate Vice . ^ . • 

President of Finance, the Controller, the Dean of 
i .1 Student Re cords ,'^he Executive Director of Univer- 

y ' sity Informatron Services, and the Director of 
^ Computer Serviceis (ex-officib) • The function of 

. t he Com mittee is to serve as the /'p olicy bo ard" ^ 

~ for^ compote " 

The activities include the establishment and re- . 
* view of all policies related to University coi^iputing, 

the -establishment and broad review of University \ 
priorities and service levels relative to computing, y-' 
regular monitoring of the ongoing project to assure . 
/ effective implementation, of the objectives 'as set 

forth in the contract, the working plan, and any .. 
other systems-related plans of the University, and . ' 
\ yearly review of the Computer Center budget consistent 
* with the service levels established.'"^ . i ' * 

The committee has a standing monthly meeting but currently meets on an 
■ as-needed basis, almost weekly. ' 

PART 4 . , , . ' 
.USER LIAISON: THE COMMUNITY CONTACT REPRESENTATIVE ' 
User- Liaison Specialists within, UIS are vitally important,- having as 
their prime fijnrtion the task -'of facilitating coitirauni cation between user , 
departments and the computer production and design staff,- Each specialist 
is assigned responsibil'ity ^or an administrative area and spends most of 
his/her time in the specific area gathering or g]'vnn3 information and 

trouble shooting apparent problems • .'. ^ 

/. •■ ^ . '/ ^ ■ - " ' ^ 

The UL Specialists who 'operate »wi thin Computer Services have been 

heavily involved in the design and implementation stages of ISIS. Spe^ \ 

cifically, UL Specialists assist in procedure writing, forms design, data- . 

• input screen design and tes'ting^ and development of data file -cojiversipn 

■'■ ^ ■ .,' ' ., ' : .-7- • . \. \ ■ 



specifications and associated testing. These functions have been eispe- 
• dally imporj^nt in Interfacing with the field engineer for the data 
"efitry device and' with the data entry supervis,or during transition periods. 

For^example, if forms were mailed to students v/hich became obsolete befo^e^ 

^all Were returned, a woVkable solution would have to be devisedto allow 

-"Inpttt-of-data-from-both -oTd-and-riew versions- of ^-t^ 

>t 7 . . • 

system modifications, procedures , and input screen design. • 

At the samp time UL Specialists interpret to the users how the system 

can best serve them^ by identifying potentiaV problem areas of design or 

J' ■* • . ' 

procedures, such as* registration and billing methods for classes with ir- 

. ■ ' ' • ■ • "* < 

regular beginning and ending dates. Ttiey assist in dev^eloping the user's . 
objecti^e§^ the design of new formats and the enumeration and clarification 
of^ required testing. ^ 

As a highly user-oriented group, they have had a primary role in • 

providing training new data collection and recording procedures to 

■»■••■» , . . ■ . 

selected personnel. To do this, UL Specialists must know and understand - 

the mechanics" of the old systems in addition to the design of the new 

system. Further, they must know the strengths and v/eaknesses of their 

users— and help reluctant users to realize benefits of coordination and 

systemization.. The day-to-.day and person-to-person contact given by User 

Liaison throughout the University community- cannot be overemphasized in 

"the process of developing and maintaining a smooth and effective system. 

y PART 5 ; ' . 

S.YSTEMS SEMINARS: THE CORE PROBLEM ATTITUDES ^ 

. ■ ' . - * ' ■• 

Because of the absolute necessity for user involvement in the 

implementation phase of the new system and because of the substantial un- • 



rest and resistance to Such a change causijig effort, there- was a need for 
some method of bringijig about unified feeling of cooperation. 

Argyris has stated that "most individuals are' 'systematicany blind' 
to their behav^ior and are' therefore 'culturally programmed' to behave iq. 
ways that reduce the probability of change ."^ , ^'^ . 



The devTcenthdsen to overcome this ""systematic blindness" was' a 
consciousness-raising model developed by Samuel" A. Culbert^^cis described in 
his book> The Organi^tion Trap> and How to (^et Out of It.- : 

The consciousness-raising model focuses on two' components J the personal 
and the system. The p^sonal component strives to develop suffici'ent under- 
stancling of who we are without our adaptations to the system and to rec-. 
ognjze which partfe of the. system fail to fit our needs! The system componeat \ 
involves olir seeing what the system is and how it works—as contrasted with 
how we've been contditioned to see it— and our thinking about the well-being 
of others who are also part of the system. In implementing the model, it 

k r . ' . * * . " ■; • \ \ ^ . ^ ^ ■ 

important to observe the following noints: (see Attachment C) 



1. The outputs of each stage prd/ide inputs for the next; thus," 
the stag[ps mUst be carried q/t in sequence.* . 

2. The groups should' be carefully selected so. .that there is a. 
cross section of. individuals at the same operational level 
but representijig different departments within Pepperdine. 

3. The group should be small enough for comfortable sh^iring but 
large enough to construct an accurate perspective of the 
system (12-15). ^ 



4. ^ The group should be committed td attend all three four-hour ' 

sessions which meet weekly for three v/eeks.. / 

5. Each- session is to be conducted by a Facilitator who sets an ; 
atmosphere of open communication. An individual from U IS, who 
is a systems specialist, should also* be a member of. the group, 
for Jthe three weeks. His/her role is to supply answers should 
any pertinent systems- related questions' of a* technical nature; 



need clarification. 
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■ • . . . ■ . ■ ■ , - J . 

6. Each seminar should be evaluated for each session both by the 
attendees (see AttachmeM'D) and by the Facilitator (see 
'/ .Attachment E).. These evaluations are then tabulated and ' 
analyzed. 

' ' ' , *. . . 

.Ideas and alternatives for changes to the systenf-be it administrative 

or computer-based—v/eiVe' jirafted -by each Seminar group in the llj^ of Action 

Items whkh were "directed to University officials. General air^as of concern| 

have been communication , quality of management, fringe benefj^s>^university- 

planning* management -.philosophy, softvtare design, and data processing op- • 

^aSons.' • ' 1/-^- . ^ , \ ^ 

Exanple^^^of the responses to such recommendations were: a trimesterly 
meeting with toptj university administrators and the staffs of each campus in • 
agpport/quesf ion/answer ftyrmat; increased benefits to personnel; better 
management di recti orr; improved coordination and communication between de- 
partments; additional training session^; clarification of r61es within the 
institution; an orientation manual to UIS for non^UIS personnel; wide dis- 
tribiition of the University organizational chart; etc. 
. PART 6 

THE- DATA BASE ADMINISTRATOR CONCEPT: DEFINITION AND SCOPE 

The Data Base, Administrator (DBA/OBM-Manager) and various views and 
roles of the position were described in an article^^ in the May, 1977 tssue 
of - DATAf^ATION , entitled "The Many Faces of the. DBA." The consistent theme 
of the article 'is there's no consistency in the position, eithep frjJm the 
standpoint of qualifications, of-saltiry, of place in the hierarch/, or of 
envloyer expectations. That's consistent with several dttifinjMTsitions we 

- could name. ' 

If there's a single knot i^ha^^^jis the individuals in the data users 
conmunity to the information they require for effective operations, it's 



4 ■ • 

probably the DBA. The DBA is to corporate data and information what the 

Director of Personne;! is to the .employer/employee, relationship in an 

organization! He or she must havd an understanding of the "organization's ' 

goals, of the information needs associated with each of the sometijnes diverse 

units comprising the organization! .of the level of S'oph.isti cation the users . 

, will bring to an EDP-managed environment, and. must have a sufficient depth 
\ • ... 

of knowledge of the limitations and capabilities of the specific data pro- 

J . . . . 

cessing resources provided by the Institution to work with systems , programmers 

• : ■ - t 

. in developmen\^f *a realistic systems design ^n the context of these para- 
" meters. The analogy with a Director of Personnel rests on the assumption" 
that the D1 rector ^st have a similar knov/ledge of the 'personnel needs in 
an organization, -be able to -systematically quantify and keep records ac- . 
cordingly, and know where, how, and what^time frames are necessary to meet , 

these needs. - - ' 

As we perceive it, the human characteristics one looks for in fillirfg a 
DBA position include not only an .intiriiaffe general .knowledge of insUtutions . 
of higher. education from a b^^ad philosophical to a nuts-and>-bolts peK^^^^^^ 
spective, but also these; • • 

. * 1. Administrative— We associate these with common sense planning 
which includes future growth, policy needs, and resources, 
planning for an organization with adequate (not surplus, not 
J deficit) human, fiscal, and physical resources;. , - 

2. Technical— A grasp of the state-of-the-art picture in both the 
changing technological environment and in terms of where 
colleges and universities might be five years from new. This 
means changes precipitated by state and federal government 
requirements, changing curriculum and student populations, 
changing emphasis on data as an institutional resource, etc.; 

- i Manaqerial- ^Speaks to one's ability to assess accurately what 

one has to work with and optimizing the utiliza'tion of those Ijfc 
resources to meet today's needs. Good procedures and training^ 

y programs accompany a good .rianager; and 

• . . -11- 
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4'. Atti tlidi na 1 -j ; We ' don ' t suppose there are more than a dozen^ / 
DBff's^in colleges and universities across the United Stall 



s 

ges and universities across the United States if 
/ with as much as ten years experience in their position'. How I 
does the DBA view himself/herself and how are they viewed Ij 
by,'j;heir employer? In the absence of arcTfearly defined and ^ / 
jndfcwjally acceptable role in the profession, how many quetlity 
DBAs will v/e have, ten years from now? Business more^-J^nd 
more viev/s Data Base Administration as a profession,^ but, 
given the Ijish-powered language v/e use to define a profes- 
sional, we 'doubt that more than S-KT^stercent-of the 3,090 . 
plus college^ and universities in th.e Ijfeted States have 
a professional DBA, You in this, room will have a signifi- / 
cant impact on answers related to "these questions between 
• .now and, say, 1980, and pur attitudes- and self-image will 
reflect your answers, . 

We have a handout (Attachment F) outlining 'the generalized job* d6- 
scription employed by Pepperdine University for its two DBAs, ^ One"^^ DBA for 
the Integrated StujJent Information System, and one for the Integrated Busi- 
ness Information System. If- these two DBAs do a workmanlike job in data 
,base development, likely a Single DBA, working with twoimanagers, ^(at a / 
considerable lower level) is all that will be required #) get our job don^' • 
,on a maintenance basis. * / 

. Wh'ile^most of what we've siid about the' DBA has been gained fr«m/direct 
experience over the past 15-18 months at Pepperdine University, soni/j'of it 
was learned by us too late*to put into optimal practice- • 
■ * PART 7 

.ADVISORT. COMMITTEES: THE INPUT FRAf-IEWORK 
Under the leadership oif the DBA and with input from all chief admin- 
istrative officers of the University, total user office representation was 
sought at the initiation of^* data base planning and design. Some 18 dif- , 
ferent offices have representatives on our Student Systems Advisory Com- 
mittee, and •approximately «he same number sit on the Business Systems 
Advisory Committee. We consider the benefits derived from the CemmitteeS 



/ 
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rof Inestimable value to the success of our systems development for the 

'" ••\- ■ ■ ■ ' ■ 

followTtw reasons: 

!• Theyoestablished a spirit of "community" effort and input 

leading to a sense of "ourness" about the system. which was . 
developed; . . t 

" ■*■•,* 

Z. I^stems oversights were caught prior to being formally 
incorporated in the design; 

3. It was easy tp identify and develop "worst case" examples 
in the desigCandJiesting.of systems flexibility; 

Jl Since our programs are systems tables', monitored, adequate ^ 
. field sizes were established in the tables oh the first 
* ' ^ pass; and^ ; ' 

5. There has been almost no negative kick-back in .the form 
qf "our office didn't know/wasn't informed in/xime to . 
fully as$e9^our needs." i 

A couple of additional insights accompanied this parti cipatory-xle- \- 

^\e1opment plan. Fi^st, things werift a hundred times better when we (the 

— <i- 

'V 

DBAs) came to the Committee with a specific proposal for each segment of 
"^tf^, system. It is^imuch more efficient to change a proposal than^to try 
to deve3op one in a committee environment. We tried to have each pro- . 
posal and" a meeting agenda in the hancfs of the Student' Systems Committed 
members at least ten days prior^o^ meetings. In this manner, each member • 
could reviiew with and solicit input from those {s)he represented. Also, 
each meeting was followed by minutes, kept and distributed by the chain- 
persoji. f-teetings wer6 held every three-to-six weeks during the system 
design. A second important advantage was gained when it was t>me to 
"s^rt user training programs, v/hich is covered in more detail later. 
Havi!<^ individuals in the training sessions who already had a good over- 
view of the system we were installing (from having had Advisory Committee 
experience) pennitte<^ a much more effective user training series than we 

-13- 
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could otherwise have expected-.^ Thirdly, . we introduced 4, system .that / 



already had a fairly broad base of s.ypport on the day! of start-up- . 

In summary, the Advisory Comittees provide valuable early input. for 
> ■ *■ • • « • 

systems design and rev'iew and, just as importantly, provide effective ^ ° 

channels for communication in an area where the importance of communication 

' . , . . / ■• • ■■ ■ / 

is indispensible and too often overlooj^ed, .• ■ ^ 

•PART 8 • ' " 



, . IMPLE^e^TATION TASK GROUPS: A MIDDLE I-IAiJAGEMENXROLE 
Several weeks follov/ing the wrap-up of our data element dictionary 
definitions, systems tables identification, and program specii^'cations, it 
became" obvious' there was no orchestrated effort to get user^initiated tasks 

j 

off the ground. Everybody seemed to be working hard but we did not appear 

to be making any sysl^fematic progress towards 'day one of implementation. 

The following events and descriptions apply only tb the student system 

# , ■ i • 

segment of our systems development, although it likely will be the case 

for the business system (if we haven't made- it- cl^ar, these systems are 

i ■ ■ 

integrated and accessed using common retrieval software^. 

It was the circumstances just described that! led to the formatioh -of 

"the student system Implementation Task Force. Itj is composed of the Dean 

Of Student Records, our two registrars, our two assistant .registrars for 

' ■ i 

data management, and the f^anager of Student Records Systems from University 

, r # ■ ' ! 

Informatioti Services. For some four months, we niet formally once a week 
following-up and following through with mutually agreed upon tasks and 
priorities. Beginning with the system start-up and the opening of the 
Fall Term, these meetings have been reduced to twice monthly. Here, in 
general terms is how our time was spent. 

-14- 



Initially, the meetings >ere devpt^ to ^rrmlating strat^y: what 
to do first and how; what followed, on.tf]rpugh to the final tasks. 

Gant charts were construeied fojr each'seg^nen^t or'module of the software. 



Our first stage development plan called for two transactign editing modules; 
a Transactional Inptut Hodul-e^ for fnacro screening; and Systems Jables, used 
wherever possibTie, as approfiriate. The action file^ \^nd/or programs^ de- 
.fined foe early use were: ^Course Catalog, Course ^$cf^<Ju 
(which handles all our registrations). Student Bntfff^^^ata/ ^ Grades 
^porting, and Reportint|/R§tifej^ -JTo these we are presently adding^" * 
modules to manage our. admissions/marketing programs, financfial aids. 



, the plan we 
e ( and. perhaps 



.^institutional research, and alumni /development. In general 
develop6cl fpr user activities can be applied to any of thes 
to most other modules.) The activities engaged in consist (pf five broad 
categories: - _ i ' 

1. Input Form design and* .I'roducti on Activities; * . 

• ■ \ i 

2. Table Definition and Construction Activities; 

• ■* , 

-3. Production- related (through to report retention) Kttivities; 
' 4. File Conversion(s), v/here applicablalv' and 



.5. Testing (which includes procedures and retrieval 
p opmeijt). ^ ^ ' * 



(see Attachi^ent'G). 

r 

Since the programs mentioned were brought up as a working system, the 



r^uest^^^vel 



Implementation Task Force has net twice month ly^to refine procedures, to ^ 
evaluate our own and other users satisfactions,' and, to begjin to identify and 

ly as frantic or 



prioritize nreeded refinements. These sessipns- aren't near 
productive as our earlier meetings bu^p^^fee^^ are just 



as desirable in 



. thef overall JSGheme of things". ' . ^' , 

• ■ ■ ■ •. /'■ ■ . ■ . ■ ■ ■ 

7 PART 9 ■ 

. ■/ . . 'THE PROCEDURES COMMITTEE :' 

RERF0R^'1ERS, REVIEWERS, CONSULTANTS AND APPROVERS 
• ..... -:, ■ : . • , < . , 

. When we talk about f system, -new or otherV/ise', we are^avyare that a 

large number of (developed and accepted procedures are necessary to make 

.the 'system, successful . .With this in mind, we identified the futrctions we . 

anticipa'ted the nucleus of the 'student system would sefrve; then, using key 

persftnneT fronj'the Student System Advisory Committee, we began itemizing 

the needed procedures. Simultaneously, the concept and, constitution of a 

Procedur^ Committee v/as ^outlined and a charge written.. The listing of , 

needed procedures collected from jpar users .was organized around the as- 

sociated software elements and put into a sort of matrix (see sample page 

Attachment H), with individuals and/or office's comprising the columns and 

,the procedure naming the rows. It was decided that e^ch procedure to. be 

'-written would require four types of input: - • * 

1 . \ Performance (writing) . ^- , , > \ ' 



2. Consulting, : - 

3. Reviewing, and - ^ » 

4. ApfJroval. x . ' 

' .Counting up the needed procedures identified with -the nine student 
sysjkems modules delcribed earlier (undisr Part 8,. Implementation Task 

Groups), "we found there were more than TOO. This effort, started at^oyt 

^ ■ , ^ • ' .... * ^ ■ ' . . 

April 19^7* reached a milestone "in late summer--a draft of each needed 

procedbwrfe These drafts have been written v/ith input from designated 

cq|^^^pSts, Teviev/ed with major users impacted, and approved by the , 
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appropriate individiu^l or office.. Using our experiences through the 
first full cycle of running student systems, 'jhe procedures^ will be 
(ind^d, are now being) refined and polished. Some side benefits, from 
h.a'v1ng this Committee with its charge areV ) 

1. A much better educated and mo aware user community; 

. * ' ' 

2. A broader sensitivity on the part of users, as to 'the over--o . 
lapping and interrelated nature of procedures; and 

• ■ ■ i » 

* . 3. User/Committee inrtiated input as to policy areas not 

adequately defined/enforced. We feel this lattec char-r , 
■ acteristic is-i^rongly indicatM/e of the type of system 
user' group that v?i 11 -maximalTy s«nve our student and 
University. publics and also indicative of a transition 

from a group of systems-naive individuals to one of 
' educated systefnnrsers. We believe th+s has been a ' 
. y . major step in the ri^ght direction. . 

: PART ,10 

. . .'''^"^ TRAINING: -APPROACH TO^Ti^it- RE AL*>AY0FF 

• Despite -the fact we thought our approach to^ J Jjser training program 

was sufficiently v;ell thought put and that overs|ghts'v70uld be non-. 

existent, hindsight has-VoTO^ that vW- • Starting with what 

we ac^lly did, we will come' back to a couple of areas we probably coj/ld 

have better managed. . ' 



Eight considerations -or stances Were used as the training model 

design. ' , - 

"1. Identification of target PoDulatiort» jrStarting -with a mting of 

every administrative and academic office,. we went module-by- 
J module through the student system software, recording for, each 
^ module the offices that would impact or be impacted by the , 

■ ieferenced data flow. The chief administrator in each of these, 
offices was asked to name a representative (more than one in 
some cases) who would be available for fl|e training series. \ 

2. Calendar— We scheduled an every Wednesdsiy morning, 8:30— s , 
12:00 noon, training session that spanned about three calendar 
w&nths. This calendar was circulated-well in advance to every 
identified participant with each session the recipient was- 



iexpected to attend, hi gh^ghted. ^ : . 

Sequence- - The schedul^e of presentations' began with .the first 
module in the student system program stream, in-eur case the 
Transaction Input /lodule, then went to Systems fables, to 
Catalog, Schedule^ etc., through Grai^e Reporting and finally 
Retrieval. / 

Group Size- »-InitiaHy we thought we could hold the groups to 
between 12-118 imembers —much to our dismay, some jcrf-the sessions, 
es.peci ally/the general introductory sessions had up to 40 
Individuals. - ' 

Reader . Xonsistency- -l7e decided early on, ^ind- later were glad: 
we had, to use; thfe same individual for the tral^ning leadership 
role (teacher) throughout the training program. This minimized 
the time loss we would have encountered due to user readjust- 
ment to teaching style and also eliminated continuity gaps^. 
we might have experienced using several leaders. 

Resourc^ Avail ability- -Every effort was ma'de to- insure the 
user manuals, .input forms, program testinfg-4wateriaT$ ^ and of 
course softv/are, were all on hand at the time, v/e j'ntroduced 
each new module. • -In the^case or two v/hen ^this was not 
possible, time wasting was >prevalent and rnorale damaged. 
Fortunateljr, the'^fe v/ere exceptions to the rule and no.t of . 
jniich conseqijence overall , but this^v/ould have been crippling 
had it beennroutinely the case. ^' - ' 

• Format" V/e used what might be called a general information 
session (GIS) to intne^ce each new student systems module.' 
Every office identified as a user was invited to be represented 
for these overview presentations. These were followed by two 
or three detailed information sessions (DIS) whereinuser 
training was provided' in a learn-by-doing/.using efrvironment. 
We strongly endorse this approach to the practical aspects 

, of training v/hich, incidentally, also served as early stage 
testing of the software (since'we exercised the live data].- 



Homework" For every hour spent in the formal training environment, 
at least an equal amount of time v/as required between sessions. 
Documentation was read, test data collected, and questions sub- 
fnitted prior to^the sessjion in v/hich the tnaterials were for- 
mally covered. 'This ^required a considerable ti me c ommitment 
from each parti cipant;^; but v/e ^think would have consumed even 
more time t\ad we attempted to do everything in a group meeting. ] 
Not doing hbmework W4S considered the worst sin the users 
committ^ 

■ ■ ■ • ■ . — \ ' 
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' . ' ; PART n 

' . * EVALUATION Af^D CONCLUSIONS: HOW ARE WE DOING? 

. This segment of «ur presentation gets at the meat of the conference 

.theme: \te expectations equal ,to reality? In looking for answers, to 
the question, we must confess at once> to the subject! vity . of the assess- 
ment. The finished products do reflect those characteristics initi.ally 
specified, and that is the beginnirig" and end of an objective assessment, 
f-iany would say", and perhaps justifiably so, there is nothing else lo / 
examine. This of course assumes the absence of human'^fraili ties and I 
persona^^ as w^Tl as a freezing of the clock. At this time the re- 
ports produced have 4been in the hands of users too short a period 
(three months) to allow for a comprehensive assessment. Data which the 
users are- accustomed to receiving are still provided but now are subject 
^0 new manipulative capabilities. There are scattered complaints from the 
-^condary user community regarding added data collection and auditing 

Vrequirements; such comments as "I spend more hours working for the 

^Admissions Office/Registrar than for my own office" are not uncommon 
(or unexpected). 

If we judge the training effojrts according to the success of users 
in exercising the system, then with one or two exceptions, this area would 
get high marks--about eight on a scale of ten, objectively. 

There are offices and individuals in our University experie'ocing 
some disappointment because they unrealistically expected more for less, 
ancf in- those. cases expectations are not equal to the achieved reality. 
We believe this reality gap is in direct proportion to the level of 
understanding and sophistication of those offices and individuals, and 
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do havct, relative to tollege and university systems specifically, .and 
to machine records keeping capabilities generally 

We thought we specified a student information system that would 
allow us to efficiently and ef^Wc^ively create and manage student 
records information; at this point, there does not appear to be any 
reason to think the system will not do just that, , 




-20- 



2S 



EKLC 



FOOTNOTES 

^ Carver, Fred' D. and Sergiovanni , Thomas J., Organizations and 
Human Behavior: Focus on Schools , McGraw-Hill Book. Co., New York, 1969, ? 
pp. 167-182. , . ^ 

' ^ Tye, Kenneth A. and Novotney, Jerrold M. , Schools in Transition: • 
The Practitioner as Change Agent, McGraw-Hill Co., New York, 1975. 

^ Ibid .,- pp. 106-110,.' 

^ Ibid. , pp. 111-113. ^ - . \ 

^ Dillard, Warren; Penrod, James; Gross ,* Frederick; and. Fastman, 
Gerald, "Agreement between Pepperdine University and Systetns and Computer 
Technology Corporation," pp. 6-7. • 

;^ - ■ "Pepperdine University Systems Committee, " 

'Unpublished Working Plan between Pepperdine and SCI. \ * 

Glans, Thomas B., et al . Management Systems , Holt, Rineihart, and , 
Winston, Inc. , New York, 1968, p.- 3. 

^ Culbert. Samuel A.. The OrganizaVibn Trap and How to GetvOut of It , 
Basic Books, New York, 1974. 

^ Luchsinger, Vincent P. ancf Dock, V. tftomas.- The Systems Approach: 
A Primer , Kendall-Hunt Publishing Co., Dubque, Ibwa, 1976, pp. 4-6.. 

-Yasaki,, Edward K. , "The Many Faces' of DBA," Datamation , May 1977, 

p. 75. 




-21- 



24 



ERIC 



miHT 

;tlOUlt$ 



JOiOW- 



(0»00(H 



ICf StAVWroitW! 

, StM; SritOOl orWSINtSS AND MA'NACtMtiNr 
S:ilDOl Of rOUrATION' 



3 ! 



MM 



<1« 



!5li 



I'll 



n 



M>1 



1^ 



1M 



HlM 



KM 



ml 



n 



in 



Ml 



»ir 



1I»M 



^n 



!K)l 



31M 



yit; 



■ % 

< » 



I 
I 

1 



si: 



SflC 



SIIH 



p. 
I 

i 
i 

il 
1 

•if' 

i 
i 



1 
1 

i 
1 

1 

I 
J 

f 



i 

I 
i 

I 

I 

I 



I 

iii 

I 
1, 



} 1^ s 



I u s 



( u s 



/.aWMir YFARShY TiiiMrsTfn 



. r.t\m Ho«H M sninow hm dip* mrm vm imm\ m/mim, 




' wmvi n mm m vit mm run \m-\w TiimiH iii7M);iii 




fERlC 



J SnrtLilfriitfJftn 




' ■ 'I 



• 32 ' : 







Operator.! 



Operator III 



Operator III |-[| Operator III 
1 



Operator II 



Operator II 



rl ' 



Operator I 1 



Operator II 



Assistant 
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Prograimer 




Supervisor 




■ Sypervlsor ' 
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SCT , " 





Lab 

[i Assistant III 
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. " ATTACHMENT 

n SYSTEMS SEMINAR 
A MODEL FOR 'increased PARTICIPANT CONSCIOUSNESS 
• / IN A PLANNED ORGAiNIZATIONAL CHANGE " . 

STAGE'! : .RECOGNIZING THE PROBLEM 

The first stage has to do with turning "feelings of incoherence" into, 
"sta tements\ of discrepancies. " Two questions which typify this are: 
"In what vyays. could this feeling be a clue that the system expects some- 
thing from me that doesn't seem natural or consistent with my self- 
interests? In v;hat v/ays couTd this feeling be. a clue that som.et-hing ' • . 
which. Seems. natural enough to me is considered' inappropriate or inadequate 
b y the system?" 1 ' ■ ' 

• STAGE 2: UNDERSTANDING OURSELVES AND THE SYSTEM . 

..Stage 'two inputs are the lists of discrepancies derived m stage one. 

'We are to use our inductive thought processes and to approach, the lists- 
as symptoms rather than 'the basic ills and. then determine what ailment • ' . 
tHese symptoms might signal— explaining why we have a difference with the 
siystem.' "If this discrepancy were a symptom of a more basic conflict, 
what, would that conflict be?, l^hat combination of human qualities and 
organizjation attributes tould have produced conflicts such as the ones we ' ' 
have identified?" , 

STAGE 3: UNDERSTANDING OU^ RELATIONSHIP WITH THE SYSTEM . • ' 

S^tage three inputs are the systems insights and the neSds and interests 

of group, members. . In this stage, v/e v/ish to explicate the assumptions on 

which our interactions with the system are based and examine how' they were - 
-formed: (1) goals v/e held" for our interactions v/ith the system and the 
/means. we, use for achieving them, (2) ' assumptions about the. system: its 

purpose, 'values, roles in SQciety, and its way of viewing us,**(3) the > ^ 
/way we and the system influence one another. Each person' s assumptions ■ 

are recorded and also an attempit to identify the origin of the assumption. 

The group needs to lend support that challenges existing premisesr beliefs, ^ 

and idiosyncratic assumptions. 

S TA6E -4: FORMULATING ALTERNATIVES : 

^ . . 

The fourth stage is designed to formulate alternatives that will improve 
oiir relatidnship to the system. This is done by examining the recorded' 
assumptions which link, f us to the system versus what v/e have learned and 
recorded about our needs, interests, and ideals. Tv/o types of alternatives, 
which may be. formul ated : ( 1 ) those whi ch improve the, way the system works 
and (2) those which change our relationship to it. These are recorded 
and input Into the next is tage. ' 
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ATTACHMENT C 



STAGE 5: AFFECTING THE LIVESi OF OTHERS * v 

•The last stage begins with the lists of alternatives, having to do with 
personal changes" and systems changes. System changes involve affecting 
the lives of others; thus there is a need to formulate strategies for 
the implementation of alternatives. It involves approaching people out- 
side of the group who in all likelihood hold very different views- It is 
best to go to such individuals with a "Statespersonlike" approach, iVi|.,. 
explore how the system can be improved rather than advocating speci fie 
improvements. 
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ATTACHfCHT D 



SYSTEMS SEMINAR 
End-of-fleeting Evaluation 
Date: 



2. 
3. 
4. 

5. 

6. 

7., 

8. 

9. 

10. 

n. 



Were you interested in 
this meeting? 



Very 

much 



Qui te 
a bit 



Some , but 
not much 



Very 
little 



Did you fefel that the group Very ' Quite 
'was interested in the meeting? much a bit_ 



Some, but 
. not much 



Very 
little 



12. 



Yes. 
many 



Qui te 
a few 



Yes, 
many 



Quite 
a few 



, Some, but 

^not very _ 

many 

Some but, 
not much 



Very fev/, 
_if any 



Very few, 
if anyj 



Very 
much 



Quite 
a bit 



Some, but 
not much 



Very 
little 



It cer-.-It pro- I doubl 
tainly bably if it 
did did did 



It 

did 

not 



Did you learn any new facts 
or get any new ideas? 

pi d you change any of your 
previ ous opi ni pns as a , - 
result of this meeting? 

Mere your previous opin- 
ions confirmed or 
strengthened? 

Did you think the group 
accomplished anything ^s 
a result of this meeting? 

' Was there enough prepara- 
tion for the meeting? ^ 

Was there enough oppor- 
tunity forifdiscussion? ^ 

Would the meeting have 
been better if some parts 
bad been left out? 

Did you find the social 
atiftosphere of the meeting 
congenial and enjoyable? 

Pleas'e give your evaluation 
(specific comments are ap- 
preciated) of the perform- 
ance of the Facilitator. 

Do you have suggestions (about techniques, materials, etc.)^or improving 
future meetings? (Use other side of page if necessary.) 



More 
than 
needed_ 

Too 
much 



All that Should have Should have 

was been , been much 

jneeded more more 

All that Should have Should |}ave 



was 

needed 



. been 
more 



been much 
more 



Certain-Probably Maybe 
ly . 



Definitely , 
not ' # 



Excel- 
lent 



Quite 
jood 



All 
right 



Definitely 
not 



Excel- 
lent' 



Quite 
.good _ 



Fair 



Poor 




(you need not sfgn your name) 



ANECDOTAL OBSERVATIONS ON MEETING PRODUCTIVITY 



A. Orientation 

' • ■ , ' . • ■ ' ^ ■, 

1. flOK far did we get? 

. 2. To what' extent did we undeptand^what 
• we are.trying to do? 

.. 3. To what extend'did we understand how, 
we ire trying to do it? 

4. To what extent were we stymied by lack 
of infonnation? 


• • • r 

* 

- . . . 1 ...... .......... 


B. Motivation and Unity 

1. Were all of us equally interested in 
, what we are trying to do? 

« 

2. Was interest maintained or did it 
lag? ^ 

..3.. To what extent did the group feel 
. united by a common purpose? 

4. To what extent were we able to sub- 
ordinate individual interests to the 
common goal? 


1 

I' 

X . .■ ... ... ■ 

-4 1— i 


C. Atmosphere 

Was the general -atmosphere of the group: 

1. ' Informal or formal? 

2. ' Permissive or inhibited? 

3. Cooperative or competitive? 

4. Friendly or hostile? 


•» ■' ■ ' ■ 

t'. 

a 

■ . . 1 

1 



•0 



0 



(0. 



• D. Cbntrlbutlons of Hembers 

•■ ,1. Mas partlcipatioff-general or lopsided? 

2. -Were contributions on the beam or off 
■ at a tangent? 

3. - O'id contributions: indicate that those 

who made them were listening carefully 
to what others in tihe group had to say? 

- 4. Were contributions factual and problem- 
centered or were the contributors un- 
able to rise above their preconceived 
notions and emotionally-held points of 
view? 



N e/ Contributions of Special fiembers of the Group 
. 1. How well did the leader s^rve the group? 



0 



• 2, The recorder? 



3, The resource persons? 

4, Those in other special roles? 



ATTACHMENT F • * . 

. ' RESPONSIBILITY S-TATEMENT 

for ' ^ 

Data Base Administrators 

■ , . . ■ • "■ • 

Under the direct guidance of the appropriate vice president (i.e., the 
Vice President for Academic Affairs regarding Admissions, Financial Aid, 
Student Academic Data, and Faculty Data; the Vice President for Financial 
Affairs regarding Financial Records and Budget Data; the Vice President 
for Administrative Affairs regarding Personnel, Position Control and 
Purchasing; and the Vice President for University Affairs regarding Alumni 
and Development Records) ra dafa bate administrator :is expected to: 

1. Participate directly in all related data file development/ 
construction beginning with records management philosophy 

0an6 continuing through'defini tion of necessary data elements 
and files formatS^; • 

2. Oversee ^nd manage the constri&rction of necessary input/ 
output forms and reports incjCua4ng approval (s) of all such 

: documents and an/ changes requested Jn their content or format; 

3. Assume responsilii 1 i ty for the integrity of and ultimate approval/ 
denial of non-routine access to the data files for such purposes 

I, as special reports, research activitie;s, etc.; 

^TJ'jflg-;^ Coordinate v/ith deans, directors, and department chairpersons 
/"^■ffikoftvvare design, data element definition , training and program 
; •^"te^ting activities, and data file. changes and maintenance. 

These responsibilities should. further insure infa^iiiation in- 

tegrity and adequacy; 

5. As a function- of maintaining the Data Base's integrity, Jt wiMl 
be the responsibility oi the Data Base Administrator to insure 
that appropriate procedures are" documentid within the guidelines 
specified by the University Procedures Committee; and 

6. Insure that state-of-the-art data management practices are employed 
to the extent Universfty physical, fiscal, and human resources 
permit. ^ . * 

"Because data from various University officfeSand areas is likely to become a 
part of any data base, the scopeof the administrator's responsibility is 
determined primarily by that, of the vice president to whom the administrator 
reports rather than by the. specific office in v/hich he or she is housed. 

The Data Base Administrator will, by position definition, be the Chairperson 
of the Systems Advisory Committee assigned the responsibility for input to 
the appropriate data area(s). The Chairperson will routinely convene this 
cinmittee on a monthly basis, be responsive to the suggestions solicited 
from the Committee, and advise the Executive Director of University Infor- 
mation Services of Committee recommendations. . 
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ATTACHMENT G 



USER MODULE- CHECKLIST 
TABLES 



s '■ ' 



-INPUT FOW'1 DESIGN . > 

A. Identify module data elements to be 
maintained and, determine all input 
forms required for the module. ■ 

* 

B. For each input form... 



1. 

2. 
3. 



Specify data elements to be 
included on the form 
Initial design 
Distribute initial di*aft 



for 



review 

Make modifications 
5.^ Write procedures for: 

a. completing the form 

b. processing the form 
Distribute final draft and pro- 
cedures .for approval (this in- 
cludes computer operations 
approval ) 

Art work for approved forms 
Distribute proof for approval 
and usage estimates 
Send 'to printer 
Printing 



4. 



6. 



7. 
8. 

9. 
10. 



TABLE DEFINITIOfJ 

A* Determine, tables required for module 
B. For each table. . . ^ 

1. Determine USE/FORr-lAT 

2. Collect/Code Table 

3* Review Output/Write maintenance 
^.^ .proc^ure (including forms if 

' 

4. - Make corrections 

5. Publicize table/maintenance 
procedures as required 



BEG 
DT. 



■9 



IND 
DT. 
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ATTACHMENT G 



USER MODULE CHECKLIST 
TABLES 



PRODUCTION 

Determine functional responsibilities 
B. ^Establish administrative . calendar 



Initial module build 
Conti nued mai ntenance 



D. 
E. 
F. 



2. 

Establish production schedule including 
standard parameter options 

Establish data entry deadlines 

Establish standard distribution 

Establish report filing/retention 
procedures 



qoriVERSiON 

7A. Review conversion specifications 

to. Establish, conversion run schedule 

C. Review conversion tests 

D. Develop procedures to handle rejects 

E. Develop procedure for collecting 
ISIS data elements which are not 
available on current system 

F. Accept conversion specs /tes,ts 



BEG 
DT. 



END 
DT. 



RESPON. PERSON 
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ATTACHr£NT G 

USER MODULE CHECKLIST 
TABLES 



1 



TESTING 



A. Review documentation 

B. Develop testing objectives • 

1. TIM edit features 

2. Table lookups 

3. Error messages 

^- 4. System generated dat^ ^ 
5. Output reports 

a. Fields print correctly i 
» \, b. Selection 

c. Sequence 

d. Format 

. ' e. Computations 

C. Code test transactions 

D. Reviev/ tests 

E. Analyze reports/processes 

1. Processes 

a. Develop general overviev/ 

b. Compare existing vs. new 

2. For each report 

a. Determine USE (especially 
viewed as a replacement 
of an existing report or 



a new tool) 
b. Write procedure for use 

as appropriate 
C. Write retreival requests 
'as appropriate 



BEG 


END 


RESPON 


, /PERSON 


DT. 


DT. 


/ 

• . / 








• ' / 
/ 

/ 
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\ 
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/ 






V j 
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/ 








• 




























t 





















page 3 of 3 



49 



ERIC 



IlliVERSin PROCBOljRis COMMITTEE 



HWI^ONSIBIUTY MATRIX 



|r^ect:;Hw?ger: 




.9 



AfiiflPitilg SuapGnslon; lst/2nd Time 
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